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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The IM CN subsystem interworks with the external IP networks through the Mb reference point. 

This document details the interworking between the IM CN subsystem and external IP networks for IM service support. 
It addresses the issues of control plane interworking, user plane interworking and IP version interworking. 

The IP version Interworking, between IP version 4 RFC 791 [9] and IP version 6 RFC 2460 [10] detailed in terms of the 
processes and protocol mappings required in order to support both mobile originated and terminated calls. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TS 24.229: "Internet Protocol (IP) multimedia call control protocol based on Session 
Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3". 

[2] IETF RFC 3261: "SIP: Session Initiation Protocol". 

[3] 3GPP TS 23.221: "Architectural requirements". 

[4] 3GPP TS 29.061: "Interworking between the Public Land Mobile Network (PLMN) supporting 

packet based services and Packet Data Networks (PDN)". 

[5] 3GPP TS 23.002: "Network architecture". 

[6] 3GPP TS 26.235: "Packet switched conversational multimedia applications; Default codecs". 

[7] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[8] 3GPP TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2". 

[9] IETF RFC 791: "Internet Protocol". 

[10] IETF RFC 2460: "Internet Protocol, Version 6 (IPv6) Specification". 

[II] IETF RFC 2766: "Network Address Translation - Protocol Translation (NAT-PT)". 

[12] IETF RFC 2663: "IP Network Address Translator (NAT) Terminology and Considerations". 

[13] 3GPP TR 29.962 version 6.1.0: "Signalling interworking between the 3GPP profile of the Session 

Initiation Protocol (SIP) and non-3GPP SIP usage". 

[14] ITU-T Recommendation H.263: "Video coding for low bit rate communication". 

[15] ITU-T Recommendation G. 723.1: "Dual rate speech coder for multimedia communications 

transmitting at 5.3 and 6.3 kbit/s". 

[16] ITU-T Recommendation G.729: "Coding of speech at 8 kbit/s using conjugate-structure algebraic- 

code-excited linear-prediction (CS-ACELP)". 

[17] ITU-T Recommendation G.711: "Pulse code modulation (PCM) of voice frequencies". 
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[18] 
[19] 

[20] 



IETF RFC 792: "Internet Control Message Protocol". 

IETF RFC 2463: "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 
6". 

IETF RFC 2765: 'Stateless IP/ICMP Translation Algorithm (SITT)". 



3.1 



Definitions, symbols and abbreviations 



Definitions 



For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [7] and the following 
apply: 

IM CN subsystem: (IP Multimedia CN subsystem) comprises of all CN elements for the provision of IP multimedia 
applications over IP multimedia sessions 

IP multimedia session: set of multimedia senders and receivers and the data streams flowing from senders to receivers 
IP multimedia sessions are supported by the IP multimedia CN Subsystem and are enabled by IP connectivity bearers 
(e.g. GPRS as a bearer). A user may invoke concurrent IP multimedia sessions. 

3.2 Symbols 

Void. 



3.3 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

CSCF Call Session Control Function 

GTP GPRS Tunnelling Protocol 

IETF STD Internet Engineering Task Force STandarD 

IM IP Multimedia 

IMS IP Multimedia Subsystem 

IMS-ALG IMS - Application Level Gateway 

IP Internet Protocol 

IPv4 IP version 4 

IPv6 IP version 6 

LAN Local Area Network 

MEGACO MEdia GAteway COntrol 

MRFC Multimedia Resource Function Controller 

MRFP Multimedia Resource Function Processor 

NA (P) T-PT Network Address (Port-Multiplexing) Translation-Protocol Translation 

PDN Packet Data Network 

QoS Quality of Service 

S-CSCF Serving-CSCF 

SIP UA SIP User Agent 

SIP Session Initiation Protocol 

TrGW Translation Gate Way 

UE User Equipment 

WAN Wide Area Network 
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4 General 

4.1 General interworking overview 

The IM CN Subsystem interworks with SIP RFC 3261 [2] based IP Multimedia networks. These IP Multimedia 
networks include: 

- SIP User Agents (UAs); 

- SIP Servers. 

As such, the IM CN Subsystem has to be able to interwork to all of these above functional entities in the IP multimedia 
network, as there is a possibility that they all may be involved in an IM session. The general interworking model is 
shown in figure 1. The SIP based Multimedia networks may use IP version 4 RFC 791 [9] or IP version 6 
RFC 2460 [10]. 
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Figure 1 : Interworking Model for IM CN Subsystem to IP Multimedia Network 

The UE uses the CSCF in order to communicate with the external IP multimedia network entities. 

If no IP version interworking or no NAT/NAPT between different realms is required, the CSCF can communicate with 
SIP UAs in an external IP multimedia network directly. 

If no IP version interworking or no NAT/NAPT between different realms is required, the CSCF can also communicate 
with SIP proxies in an external IP multimedia network directly, which in turn can then communicate with SIP UAs. 

To provide the IP version interworking or NAT/NAPT between different realms the functions of an IMS-ALG and a 
TrGW may be inserted between the CSCF and external IP Multimedia Network by configuration. The IMS-ALG and 
the TrGW may be implemented as a part of other physical entities in the IMS. 

NOTE: Other methods to provide IP version interworking are for further study. 



4.2 Interworking scenarios 



3GPP specifications design the IM CN subsystem elements and interfaces to exclusively support IPv6. 
3GPP TS 23.221 [3] details the interoperability scenarios that an UE may experience when interworking with an 
external PDN. All of these IP transport layer interworking scenarios can apply to the application layer interworking 
scenarios detailed in clause 4.2.1. 
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4.2.1 UE with 3GPP SIP profile capability connecting to an external SIP 
device 

The procedures used by an UE with 3GPP SIP profile to connect to an external SIP device, which may lack 3GPP SIP 
profile capabilities, have been analysed in Release 6 within 3GPP TR 29.962 [13] and are specified in 3 GPP TS 24.229 
[1]. 



5 Network characteristics 

5.1 Key characteristics of IP IVIultimedia Networks 

The Internet is a conglomeration of networks utilising a common set of protocols. IP protocols are defined in the 
relevant IETF RFCs. The networks topologies may be based on LANs (e.g. Ethernet), Point-to-Point leased lines, 
PSTN, ISDN, X.25 or WANs using switched technology (e.g. SMDS, ATM). 

IP multimedia networks provide the ability for users to invoke IP multimedia applications in order to send and receive 
(where applicable) voice and data communications. One protocol used to manage IP multimedia sessions is the Session 
Initiation Protocol (SIP) (RFC 3261 [2]). 

5.2 Key characteristics of UIVITS IIVI CN Subsystem 

The UMTS IM CN subsystem uses the SIP protocol to manage IP multimedia sessions, and uses IP as the transport 
mechanism for both SIP session signalling and media transport. 

The UMTS IM CN subsystem shall support interworking with existing fixed and mobile voice and IP data networks, 
including PSTN, ISDN, Mobile and Internet. 



6 Interworking Reference IVIodel for control plane 

interworking and user plane interworking 

Figure 2 details the reference architecture required to support interworking between the IM CN subsystem and IP 
networks for IM services. Figure 3 details the reference architecture required to support interworking between the IMS 
and IP SIP networks supporting IP version 4. 
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-I- 
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Mb 

NOTE: Multimedia IP networks may be connected via the Mb interface to various network entities, such as an UE 
(via an GTP Tunnel reaching to the GGSN), an MRFP, or an application server. 

Figure 2: IM CN Subsystem to IP network interworking reference Architecture without IP version 

interworking 
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Figure 3: Border Control Functions 

Mm reference point: The call control protocol applied to the Mm interface between CSCF and external IP networks is 
SIP, RFC 3261 [2], as detailed in 3GPP TS 24.229 [1]. SIP extension packages mandated by 3GPP are possibly not 
supported. 

Mb reference point: This interface is defined in 3GPP TS 23.002 [5] and is IP based. Further information is provided 
in 3GPP TS 29.061 [4] and 3GPP TS 26.235 [6]. 

Mx reference point: The protocol applied at the Mx reference point is not specified within this release of the 
specification. 

Ix reference point: The protocol applied at the Ix reference point is not specified within this release of the 
specification. 

6.1 Interworking Functional Entities 

6.1.1 S-CSCF 

This entity provides control plane functionality to connect entities following the 3GPP profile of SIP, TS 24.229 [1], 
and external SIP entities following RFC 3261 [2]. 

6.1.2 IIVIS-ALG 

IMS-ALG functionality resides in IBCF. An IMS-ALG provides the application level translation function for SIP and 
SDP in order to communicate between IPv6 and IPv4 SIP applications or, based on operator policies between different 
realms using the same IP version. The IBCF acts as a B2BUA when it performs IMS-ALG functionality. 

6.1.3 TrGW 

The TrGW is a NAT-PT/NAPT-PT, which uses a pool of globally unique IPv4 addresses for assignment to IPv6 nodes 
on a dynamic basis as sessions are initiated across the IP version boundaries. NAT-PT binds addresses in IPv6 network 
with addresses in IPv4 network and vice versa to provide transparent routing between the two IP domain without 
requiring any changes to end points. NAPT-PT provides additional translation of transport identifier (TCP, SCTP and 
UDP port numbers). More detailed information on the NAT-PT/NAPT-PT is given in RFC 2766 [11] and RFC 2663 
[12]. 
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The TrGW may provide NAT/NAPT functionality between two disparate address realms. 

7 Control plane interworking 

7.1 SIP with 3GPP Profile to Standard SIP Interworking 

3GPP TS 24.229 [1] defines the procedures, which allow a 3GPP-IMS UE to connect to a standard SIP terminal. 



8 User Plane Interworking 

8.1 Overview 

The present specification addresses user plane interworking between codec types used for either speech or video. 
Codecs used for conversational services in the PS domain are as defined in 3GPP TS 26.235 [6]. Codecs of particular 
interest are described in annex A 



8.2 Transparent User Plane 



The user plane may be transported through the IM CN subsystem without being processed by any IM CN subsystem 
entity. 



8.3 Non Transparent User Plane 



The MRFP may provide transcoding of the user plane if a codec mismatch occurs. It is not specified in the present 
release how the MRFP is inserted and controlled to provide transcoding. 



9 IP Version Interworking at the IMS-ALG/TrGW 

9.1 Control plane interworking 

9.1 .1 Originating Session Set-up to IPv4 SIP network 

9.1 .1 .1 Receipt of the first SDP offer 

At the receipt of the first SDP offer the IMS-ALG: 

Provides to the TrWG the IPv6 address(es) and port number(s) as received in the c-line(s) and m-line(s) in the 
SDP, and 

Requests the TrGW to bind corresponding IPv4 address(es) and port number(s) from its pool to the received 
IPv6 address(es) and port number(s) to enable the routing of user plane traffic from the IPv4 SIP network 
through the TrGW. 

When the IMS-ALG has received the requested information from the TrGW the IMS-ALG shall include the IPv4 
address(es) and port number(s) in a new offer, which shall be sent to the IPv4 network. The IMS-ALG shall create a SIP 
message in accordance with the rules for the IMS_ALG described in subclause 9.1.4 with the following clarification: 

The IPv4 address(es) and port number(s) shall replace the IPv6 address(es) and port number(s) in the SDP. 
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9.1 .1 .2 Receipt of the first SDP answer 

At the receipt of the first SDP answer from the IPv4 network the IMS-ALG: 

Provides to the TrGW the IPv4 address(es) and port number(s) as received in the c-line(s) and m-line(s) in the 
SDP, and 

Requests the TrGW to bind corresponding IPv6 address(es) and port number(s) from its pool to the received 
IPv4 address(es) and port number(s) to enable the routing of user plane traffic towards the IPv4 SIP network 
through the TrGW. 

When the IMS-ALG has received the requested information, the IMS-ALG shall send an SDP answer to the IPv6 
network. The IMS-ALG shall create the SIP message in accordance with the rules for the IMS ALG described in 
subclause 9.1.4 with the following clarification: 

The IPv6 address(es) and port number(s) shall replace the received IPv4 address(es) and port number(s) in the 
SDP. 

9.1 .2 Terminating Session set-up from IPv4 SIP network 

9.1.2.1 Receipt of an SDP offer 

At the receipt of the first SDP offer the IMS-ALG: 

Provides to the TrGW the IPv4 address(es) and port number(s) as received in the c-lin(es) and m-lin(es) in the 
SDP, and 

Requests the TrGW to bind corresponding IPv6 address(es) and port number(s) from its pool to the received 
IPv4 address(es ) and port number(s) to enable the routing of user plane traffic towards the IPv4 SIP network 
through the TrGW. 

When the IMS-ALG has received the requested information from the TrGW the IMS-ALG shall send an SDP offer to 
the IPv6 network. The IMS-ALG shall create a SIP message in accordance with the rules for the IMS ALG described in 
subclause 9.1.4 with the following clarifications: 

The IPv6 address(es) and port number(s) shall replace the received IPv4 address(es) and port number(s) in the 
SDP. 

9.1.2.2 Receipt of SDP answer 

At the receipt of a SDP answer from the IPv6 network the IMS-ALG: 

Provides to the TrGW the IPv6 address(es) and port number(s) as received in the c-line(s) and m-line(s) in the 
SDP. 

Requests the TrGW to bind corresponding IPv4 address(es) and port number(s) from its pool with the received 
IPv6 address(es) and port number(s) to enable the routing of user plane traffic from the IPv4 SIP network 
through the TrGW. 

When the IMS-ALG has received the requested information, the IMS-ALG shall send a SDP answer to the IPv4 
network. The IMS-ALG shall create the SIP message in accordance with the rules for the IMS ALG described in 
subclause 9.1.4 with the following clarification: 

The IPv4 address(es) and port number(s) shall replace the received IPv6 address(es) and port number(s) in the 
SDP. 

9.1 .3 Change of connection information 

After the dialog is established it is possible for both ends of the session to change the connection data for the session. 
When the IMS-ALG/TrGW receives a SDP offer/answer where port number(s) or IP address(es) is included., there are 
four different possibilities: 
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1) IP address(es) or/and port number(s) have been added. In this case additional binding(s) shall be provided by the 
IMS-ALG/TrGW as detailed for the first SDP offer in the Clauses above; 

2) IP address(es) or/and port number(s) have been deleted. In this case binding(s) shall be made free by the IMS- 
ALG/TrGW; 

3) IP address(es) and port number(s) have been reassigned of the users. In this case the binding(s) shall reflect the 
reassignment; 

4) No change has been made to the IP address(es) and port number(s). In this case no change shall be made to the 
existing binding(s). 

9.1 .4 Interworking of SIP messages 

The IMS-ALG behaves as a SIP B2BUA when interworking SIP messages. The IMS-ALG shall forward all SIP 
messages transparently with respect to all methods, result codes, headers and attachments except as follows: 

- The IMS-ALG modifies SDP according to subclauses 9.L1, 9.L2 and 9.L3; 

When forwarding an incoming SIP request, the IMS-ALG should perform UAC procedures towards the intended 
target according to IETF RFC 3261 [2], by modifying those headers necessary to ensure that all transactions 
within the dialog pass through the IMS-ALG; 

When forwarding an incoming SIP response, the IMS-ALG should perform UAS procedures towards the 
originator of the corresponding request according to IETF RFC 3261 [2], by modifying those headers necessary 
to ensure that all transactions within the dialog pass through the IMS-ALG and 

The IMS-ALG may perform any appropriate error recovery procedures in the event that an incoming message 
contains errors inconsistent with the forwarding procedures above. 

At the receipt of a BYE request, CANCEL request or non-200 final response, the IMS-ALG shall release the session 
and request the TrGW to release the bindings established for the session. 

9.2 User plane transport 

9.2.1 Payload transport 

The TrGW shall use the established bindings described above to transport the messages between the IPv6 network and 
IPv4 network in the following way. 

At the receipt of a payload message the TrGW shall: 

Replace the received IPv4 address(es) and port number(s) in the payload message with the corresponding IPv6 
address(es) and port number(s). 

Replace the received IPv6 address(es) and port number(s) in the payload message with the corresponding IPv4 
address(es) and port number(s). 

9.2.2 IP header interworking 
9.2.2.1 IPv4 to IPv6 

When the TrGW receives an IPv4 message the following codings shall be set in the IPv6 headers of the message sent to 
the IPv6 network. 

If the DP bit is set and the packet is not a fragment (i.e., the MF flag is not set and the Fragment Offset is zero) 
The IPv6 headers shall be set as described in Table 1 ; 

If the DF bit is not set or the packet is a fragment the IPv6 headers shall be set as described in Table 2. 
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Table 1 : Derivation of IPv6 Header from IPv4 header (no fragmentation) 



IPv6 field 


Value 


Version 


6 


Traffic Class: 


The default behaviour is that the 
value of the IPv6 field Traffic Class 
field is the value of the IPv4 Type 
Of Service field (all 8 bits are 
copied). An implementation of a 
TrGW should also provide the ability 
to ignore the value of the IPv4 Type 
of Service and always set the IPv6 
traffic class field to zero. 


Flow label 


The Ipv6 Flow Label Field is set to 
(all zero bits) 


Payload Length 


The IPv6 Payload Length field value 
is the IPv4 Total length field value 
minus the size of the IPv4 header 
and IPv4 options field length, if 
present. 


Next Header 


The Ipv6 Next Header value is 
copied from IPv4 Protocol field 


Hop Limit: 


The IPv6 Hop Limit value is The 
value of IPv4 field Time To Live 
minus 1 


Source Address 


Shall be handled as the addresses 
of the payload message as 
described in subclause 9.2.1 . 


Destination Address 


Shall be handled as the addresses 
of the payload message as 
described in subclause 9.2.1 . 



Table 2: Derivation of IPv6 Header from IPv4 Header (fragmentation) 



IPv6 field 


Value 


Version 


6 


Traffic Class: 


The default behaviour is that the 
value of the IPv6 field Traffic Class 
field is the value of the IPv4 Type 
Of Service field (all 8 bits are 
copied). An implementation of a 
TrGW should also provide the ability 
to ignore the value of the IPv4 Type 
of Service and always set the IPv6 
traffic class field to zero. 


Flow label 


The Ipv6 Flow Label Field is set to 
(all zero bits) 


Payload Length 


The IPv6 Payload Length field value 
is the IPv4 Total length field value 
plus 8 for the fragment header 
minus the size of the IPv4 header 
and IPv4 options field length, if 
present. 
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IPv6 field 


Value 


Version 


6 


Next Header 


The IPv6 Next header field is set to 
Fragment header (44). 


Hop Limit; 


The IPv6 Hop Limit value is The 
value of IPv4 field Time To Live 
minus 1 


Source Address 


Shall be handled as the addresses 
of the payload message as 
described in subclause 9.2.1 . 


Destination Address 


Shall be handled as the addresses 
of the payload message as 
described in subclause 9.2.1 . 


Fragments headers 

a) next header 

b) fragment Offset 

c) More fragment bit 

d) Identification 


Copied from IPv4 Protocol field 
Copied from the IPv4 Fragment 
offset field 

Copied from the value of the more 
fragment bit in the IPv4 flags field 
The low-order 16 bits copied from 
IPv4 Identification field. The high- 
order 16 bits set to zero. 



9.2.2.2 



Abnormal cases 



If IPv4 options are present in the IPv4 packet, they should be ignored i.e., there is no attempt to translate them. 
However, if an unexpired source route option is present then the packet shall instead be discarded, and an ICMPv4 
"destination unreachable/source route failed" Type 3/Code 5 error message shall be returned to the sender as defined in 
IETF RFC 792 [16] 

When a translator receives the first fragment of a fragmented UDP IPv4 packet and the checksum field is zero the 
translator should drop the packet and generate a system management event specifying at least the IP addresses and port 
numbers in the packet. When it receives fragments other than the first it should silently drop the packet since there is no 
port information to log. 

When a translator receives an unfragmented UDP IPv4 packet and the checksum field is zero the translator shall 
compute the missing UDP checksum as part of translating the packet. Also, the translator should maintain a counter of 
how many UDP checksums are generated in this manner. 



9.2.2.3 



IPv6 to IPv4 



When the TrGW receives an IPv6 message the following codings shall be set in the IPv4 headers of the message sent to 
the IPv4 network. 

If there is no IPv6 fragment header the IPv4 header fields shall be set as described in Table 3; 

If there is no IPv6 fragment header the IPv4 header fields shall be set as described in Table 3; 

Table 3: Derivation of IPv4 Header from IPv6 Header (no fragmentation) 



IPv4 field 


Value 


Version 


4 


Internet header length 


5 (No IPv4 options) 


Type of Service 


The default behaviour is that the 
value of the IPv4 field Type of 
service field is the value of the IPvB 
Traffic class field (all 8 bits are 
copied). An implementation of a 
TrGW should also provide the ability 
to ignore the value of the IPvB 
Traffic Class and always set the 
IPv4 Type of Service field to zero. 




The IPv4 Total Length field value is 
the IPv6 Payload length value plus 
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IPv4 field 


Value 


Version 


4 


Total length 


the size of the IPv4 headers. 


Identification 


All bits are set to zero 


Flags 


The more fragment flag is set to 
zero. The Don"t fragment flag is set 
to one. 


Fragment offset 


Set to zero 


Time to live (TTL) 


The value of the field shall be set to 
the received IPv6 Hop Limit field 
value minus 1. 


Protocol 


The IPv4 field Protocol shall be set 
to the value of IPv6 field The next 
header value. 


Header checksum 


Computed once the IPv4 header 
has been created. 


Source Address 


Shall be handled as the addresses 
of the payload message as 
described in subclause 9.2.1 . 


Destination Address 


Shall be handled as the addresses 
of the payload message as 
described in subclause 9.2.1 . 



Table 4: Derivation of IPv4 Header from IPv6 Header (fragmentation) 



IPv4 field 


Value 


Version 


4 


Internet header length 


5 (No IPv4 options) 


Type of Service and Precedence: 


The default behaviour is that the 
value of the IPv4 field Type of 
service field is the value of the IPv6 
Traffic class field (all 8 bits are 
copied). An implementation of a 
TrGW should also provide the ability 
to ignore the value of the IPv6 
Traffic Class and always set the 
IPv4 Type of Service field to zero. 


Total length 


The IPv4 Total Length field value is 
the IPv6 Payload length value plus 
the size of the IPv4 headers minus 
8 for the Fragment header, 


Identification 


The IPv4 Identification field is 
copied from the low-order 16-bits in 
the IPv6 identification field in the 
IPv6 Fragment header. 


Flags 


The IPv4 the More Fragments flag 
is copied from the IPv6 M flag in the 
IPv6Fragment header the IPv4 he 
Don't Fragments flag is set to zero 
allowing this packet to be 
fragmented by IPv4 routers. 


Time to live (TTL) 


The value of the field shall be set to 
the received IPv6 Hop Limit field 
value minus 1. 


Protocol 


The IPv4 field Protocol shall be set 
to the value of IPv6 field The next 
header value. 


Header checksum 


Computed once the IPv4 header 
has been created 


Source Address 


Shall be handled as the addresses 
of the payload message as 
described in subclause 9.2.1 . 


Destination Address 


Shall be handled as the addresses 
of the payload message as 
described in subclause 9.2.1 . 
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9.2.2.4 Abnormal cases 

If any of an IPv6 hop-by-hop options header, destination options header, or routing header with the Segments Left field 
equal to zero are present in the IPv6 packet, they are ignored i.e., there is no attempt to translate them. However, the 
Total Length field and the Protocol field shall be adjusted to "skip" these extension headers. 

If a routing header with a non-zero Segments Left field is present then the packet shall be translated, and an ICMPv6 
"parameter problem/ erroneous header field encountered" Type 4/Code error message as defined in IETF RFC 2463 
[17], with the Pointer field indicating the first byte of the Segments Left field should be returned to the sender. 

9.2.3 Fragmentation 

If the DF flag is not set and the IPv4 packet will result in an IPv6 packet larger than 1280 bytes the TrGW shall prior to 
transferring it in the IPv6 network: 

Add the fragment header to the message 

Fragment the IPv4 packets so that their length, excluding the IPv4 header, is at most 1232 bytes (1280 minus 40 
for the IPv6 header and 8 for the Fragment header). 

9.2.4 Abnormal cases 

As a part of decrementing the Time To Live /Hop Limit value and the TrGW discovers that the zero value is reached 
the TrGW shall send an ICMPv4/ICMPv6 message with the error 'time to live exceeded in transit' type 1 1 code as 
defined in IETF RFC 792 [16] and 'hop limit exceeded in transit' type 3 code as defined in IETF RFC 2463 [17]. 
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Annex A (informative): 

Codecs used for conversational services 

Codecs used for Conversational Services For codecs for conversational services in the PS domain are defined according 
to 3GPP TS 26.235 [6]. These include: 

Narrowband speech: The support of the AMR codec is mandated. 

For wideband speech: The support of the AMR-WB codec is mandated 

For video: The support of the H.263 profile level 10 vl is mandated, and the support of MPEG4 visual sp @ 
level and ITU-T Recommendation H.263 [14] profile 3 level 10 are optional. 

In non-3GPP SIP networks there are no mandatory codecs. However, the following codecs are of interest: 

Narrowband speech: ITU-T Recommendations G. 723.1 [15], G.729 [16] and G.711 [17] are known to be 
commonly deployed. 

Video codecs: ITU-T Recommendation H.263 [14] and MPEG4 are expected to be used. 
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